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STALKING THE WILY HACKER 


An astronomer-turned-sleuth traces a German trespasser on our military 
networks, who slipped through operating system security holes and browsed 
through sensitive databases. Was it espionage? 


CLIFFORD STOLL 


In August 1986 a persistent computer intruder attacked 
the Lawrence Berkeley Laboratory (LBL). Instead of 
trying to keep the intruder out, we took the novel ap¬ 
proach of allowing him access while we printed out his 
activities and traced him to his source. This trace back 
was harder than we expected, requiring nearly a year 
of work and the cooperation of many organizations. 
This article tells the story of the break-ins and the 
trace, and sums up what we learned. 

We approached the problem as a short, scientific ex¬ 
ercise in discovery, intending to determine who was 
breaking into our system and document the exploited 
weaknesses. It became apparent, however, that rather 
than innocuously playing around, the intruder was us¬ 
ing our computer as a hub to reach many others. His 
main interest was in computers operated by the mili¬ 
tary and by defense contractors. Targets and keywords 
suggested that he was attempting espionage by re¬ 
motely entering sensitive computers and stealing data; 
at least ho exhibited an unusual interest in a few, spe¬ 
cifically military topics. Although most attacked com¬ 
puters were at military and defense contractor sites, 
some were at universities and research organizations. 
Over the next 10 months, we watched this individual 
attack about 450 computers and successfully enter 
more than 30. 

1'his work was supported in part by the U.S, Department of Energy, under 
Contract DE-AC03-76SF00098. 
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LBL is a research institute with few military con¬ 
tracts and no classified research (unlike our sister labo¬ 
ratory, Lawrence Livermore National Laboratory, 
which has several classified projects). Our computing 
environment is typical of a university: widely distrib¬ 
uted, heterogeneous, and fairly open. Despite this lack 
of classified computing, LBL’s management decided to 
take the intrusion seriously and devoted considerable 
resources to it, in hopes of gaining understanding and a 
solution. 

The intruder conjured up no new methods for break¬ 
ing operating systems; rather he repeatedly applied 
techniques documented elsewhere. Whenever possible, 
he used known security holes and subtle bugs in dif¬ 
ferent operating systems, including UNIX,® VMS,® 
VM-TSO,® EMBOS,® and SAIL-WAITS. Yet it is a mis¬ 
take to assume that one operating system is more 
secure than another: Most of these break-ins were pos¬ 
sible because the intruder exploited common blunders 
by vendors, users, and system managers. 

Throughout these intrusions we kept our study a 
closely held secret. We deliberately remained open to 
attacks, despite knowing the intruder held system-man¬ 
ager privileges on our computers. Except for alerting 
management at threatened installations, we communi- 


UNIX is a registered trademark of AT&T Bell Laboratories. 

VMS is a registered trademark of Digital Equipment Corporation. 

VM-TSO is a registered trademark of Internationa) Business Machines Corpo¬ 
ration. 

EMBOS i.s a registered trademark of Ef.X.SI, 
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cated with only a few trusted sites, knowing this in¬ 
truder often read network messages and even accessed 
computers at several computer security companies. We 
remained in close touch with law-enforcement officials, 
who maintained a parallel investigation. As this article 
goes to press, the U.S. FBI and its German equivalent, 
the Bundeskriminalamt (BKA], continue their investiga¬ 
tions. Certain details are therefore necessarily omitted 
from this article. 

Recently, a spate of publicity surrounded computer 
break-ins around the world [23, 33, 37]. With a few 
notable exceptions (e.g., [24, 36]), most were incom¬ 
pletely reported anecdotes [7] or were little more than 
rumors. For lack of substantive documentation, system 
designers and managers have not addressed important 
problems in securing computers. Some efforts to tighten 
security on common systems may even be misdirected. 
We hope that lessons learned from our research will 
help in the design and management of more secure 
systems. 

How should a site respond to an attack? Is it possible 
to trace the connections of someone trying to evade 
detection? What can be learned by following such an 
intruder? Which security holes were taken advantage 
of? How responsive was the law-enforcement commu¬ 
nity? This article addresses these issues, and avoids 
such questions as whether there is anything intrinsi¬ 
cally wrong with browsing through other people’s files 
or with attempting to enter someone else’s computer, or 
why someone would wish to read military databases. 
Nonetheless, the author holds strong opinions on these 
subjects.’ 

DETECTION 

We first suspected a break-in when one of LBL’s com¬ 
puters reported an accounting error. A new account 
had been created without a corresponding billing ad- 
dre.ss. Our locally developed accounting program could 
not balance its books, since someone had incorrectly 
added the account. Soon afterwards, a message from 
the National Computer Security Center arrived, report¬ 
ing that someone from our laboratory had attempted to 
break into one of their computers through a MILNET 
connection. 

We removed the errant account, but the problem re¬ 
mained. We detected someone acting as a system man¬ 
ager, attempting to modify accounting records. Realiz¬ 
ing that there was an intruder in the system, we in¬ 
stalled line printers and recorders on all incoming 
ports, and printed out the traffic. Within a few days, the 
intruder showed up again. We captured all of his key¬ 
strokes on a printer and saw how he used a subtle bug 
in the Gnu-Emacs text editor [40] to obtain system- 
manager privileges. At first we suspected that the cul¬ 
prit was a student prankster at the nearby University of 
California. We decided to catch him in the act, if possi- 


’ Friendly reader, if you have forgotten Thompson’s article “Reflections on 
Trusting Trust" (44). drop this article and run to your nearest library. Con¬ 
sider his moral a]ong.side the dry ca.se .study presented here. 


ble. Accordingly, whenever the intruder was present, 
we began tracing the line, printing out all of his activity 
in real time. 

ORGANIZING OUR EFFORTS 

Early on, we began keeping a detailed logbook, summa¬ 
rizing the intruder’s traffic, the traces, our suspicions, 
and interactions with law-enforcement people. Like a 
laboratory notebook, our logbook reflected both confu¬ 
sion and progress, but eventually pointed the way to 
the solution. Months later, when we reviewed old log¬ 
book notes, buried clues to the intruder’s origin rose to 
the surface. 

Having decided to keep our efforts invisible to the 
intruder, we needed to hide our records and eliminate 
our electronic messages about his activity. Although we 
did not know the source of our problems, we trusted 
our own staff and wished to inform whoever needed to 
know. We held meetings to reduce rumors, since our 
work would be lost if word leaked out. Knowing the 
sensitivity of this matter, our staff kept it out of digital 
networks, bulletin boards, and, especially, electronic 
mail. Since the intruder searched our electronic mail, 
we exchanged messages about security by telephone. 
Several false electronic-mail messages made the in¬ 
truder feel more secure when he illicitly read them. 

MONITORS, ALARMS, AND TRAFFIC ANALYSIS 

We needed alarms to instantly notify us when the in¬ 
truder entered our system. At first, not knowing from 
which port our system was being hit, we set printers on 
all lines leading to the attacked computer. After finding 
that the intruder entered via X.25 ports, we recorded 
bidirectional traffic through that set of lines. These 
printouts proved essential to our understanding of 
events; we had records of his every keystroke, giving 
his targets, keywords, chosen passwords, and methodol¬ 
ogies. The recording was complete in that virtually all 
of these sessions were captured, either by printer or on 
the floppy disk of a nearby computer. These monitors 
also uncovered several other attempted intrusions, un¬ 
related to those of the individual we were following. 
Off-line monitors have several advantages over moni- 

What Is a Hacker? 

The term hacker has acquired many meanings, including, a 
creative programmer, one who illicitly breaks into computers, 
a novice golfer who digs up the course, a taxicab driver, and 
ditch-digger. Confusion between the first two interpretations 
results in the perception that one need be brilliant or creative 
to break into computers. This may not be true. Indeed, the 
person we followed was patient and plodding, but hardly 
showed creative brilliance in discovering new security flaws. 

To point out the ambiguity of the word hacker, this paper 
uses the term in the title, yet avoids it in the text. 

Alternatives for describing someone who breaks into com¬ 
puters are: the English word "Cracker,” and the Dutch term 
“Computerredebrenk” [14], (literally, computer peace distur¬ 
ber). The author’s choices include “varmint,” “reprobate," 
“swine,” and several unprintable words. 
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tors embedded in an operating system. They are invisi¬ 
ble even to an intruder with system privileges. More¬ 
over, they gave printouts of the intruder’s activities on 
our local area network (LAN), letting us see his at¬ 
tempts to enter other closely linked computers. A mon¬ 
itor that records keystrokes within an operating system 
consumes computing resources and may slow down 
other processes. In addition, such a monitor must use 
highly privileged software and may introduce new se¬ 
curity holes into the system. Besides taking up re¬ 
sources, on-line monitors would have warned the in¬ 
truder that he was being tracked. Since printers and 
personal computers are ubiquitous, and because RS-232 
serial lines can easily be sent to multiple receivers, we 
used this type of off-line monitor and avoided tamper¬ 
ing with our operating systems. 


From the intruder's viewpoint, almost 
everyone except LBL detected his activity. 
In reality, almost nobody except LBL 
detected him. 


The alarms themselves were crude, yet effective in 
protecting our system as well as others under attack. 
We knew of researchers developing expert systems that 
watch for abnormal activity [4, 35], but we found our 
methods simpler, cheaper, and perhaps more reliable. 
Backing up these alarms, a computer loosely coupled 
into our LAN periodically looked at every process. 

Since we knew from the printouts which accounts had 
been compromised, we oniy had to watch for the use of 
these stolen accounts. We chose to place alarms on the 
incoming lines, where serial line analyzers and per¬ 
sonal computers watched all traffic for the use of stolen 
account names. If triggered, a sequence of events cul¬ 
minated in a modem calling the operator’s pocket 
pager. The operator watched the intruder on the moni¬ 
tors. If the intruder began to delete files or damage a 
system, he could be immediately disconnected, or the 
command could be disabled. When he appeared to be 
entering sensitive computers or downloading sensitive 
files, line noise, which appeared to be network glitches, 
could be inserted into the communications link. 

In general, we contacted the system managers of the 
attacked computers, though in some cases the FBI or 
military authorities made the contact. Occasionally, 
they cooperated by leaving their systems open. More 
often, they immediately disabled the intruder or denied 
him access. From the intruder’s viewpoint, almost 
everyone except LBL detected his activity. In reality, 
almost nobody except LBL detected him. 

Throughout this time, the printouts showed his inter¬ 
ests, techniques, successes, and failures. Initially, we 
were interested in how the intruder obtained system- 
manager privileges. Within a few weeks, we noticed 
him exploring our network connections—using ARPA¬ 
NET and MILNET quite handily, but frequently need¬ 


ing help with lesser known networks. Later, the moni¬ 
tors showed him leapfrogging through our computers, 
connecting to several military bases in the United 
States and abroad. Eventually, we observed him attack¬ 
ing many sites over Internet, guessing passwords and 
account names. 

By studying the printouts, we developed an under¬ 
standing of what the intruder was looking for. We also 
compared activity on different dates in order to watch 
him learn a new system, and inferred sites he entered 
through pathways we could not monitor. We observed 
the intruder’s familiarity with various operating sys¬ 
tems and became familiar with his programming style. 
Buried in this chatter were clues to the intruder’s loca¬ 
tion and persona, but we needed to temper inferences 
based on traffic analysis. Only a complete trace back 
would identify the culprit. 

TRACE BACKS 

Tracing the activity was challenging because the in¬ 
truder crossed many networks, seldom connected for 
more than a few minutes at a time, and might be active 
at any time. We needed fast trace backs on several 
systems, so we automated much of the process. Within 
seconds of a connection, our alarms notified system 
managers and network control centers automatically, 
using pocket pagers dialed by a local modem [42]. 
Simultaneously, technicians started tracing the net¬ 
works.^ 

Since the intruder’s traffic arrived from an X.25 port, 
it could have come from anywhere in the world. We 
initially traced it to a nearby dial-up Tymnet port, in 
Oakland, California. With a court order and the tele¬ 
phone company’s cooperation, we then traced the dial¬ 
up calls to a dial-out modem belonging to a defense 
contractor in McLean, Virginia. In essence, their LAN 
allowed any user to dial out from their modem pool 
and even provided a last-number-redial capability for 
those who did not know access codes for remote sys¬ 
tems. 

Analyzing the defense contractor’s long-distance tele¬ 
phone records allowed us to determine the extent of 
these activities. By cross-correlating them with audit 
trails at other sites, we determined additional dates, 
times, and targets. A histogram of the times when the 
intruder was active showed most activity occurring at 
around noon, Pacific time. These records also demon¬ 
strated the attacks had started many months before de¬ 
tection at LBL. 

Curiously, the defense contractor’s telephone bills 
listed hundreds of short telephone calls all around the 
United States, The intruder had collected lists of mo¬ 
dem telephone numbers and then called them over 


^The monitoring and trace-back efforts mixed frustration with excitement- If 
the computer was hit at 4:00 A.M.. by 4:02. the author was out of bed, logged 
inlo several computers, and talking with the FBI. Telephone technicians in 
Germany, as well as network controllers in Europe and stateside, awaited the 
signal, so we had to eliminate false alarms, yet spread the word immediately. 
Several intimate evenings were spoiled by the intruder setting off the alarms, 
and a Halloween party was delayed while unwinding a particularly convo¬ 
luted connection. 
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these modems. Once connected, he attempted to log in 
using common account names and passwords. These 
attempts were usually directed at military bases; sev¬ 
eral had detected intruders coming in over telephone 
lines, but had not bothered to trace them. When we 
alerted the defense contractor officials to their problem, 
they tightened access to their outbound modems and 
there were no more short connections. 


We baited the intruder by creating several 
files of fictitious text... [that] appeared to 
be memos about how computers were to 
support research for SDL 


After losing access to the defense contractor’s mo¬ 
dems, the still undeterred intruder connected to us 
over different links. Through the outstanding efforts of 
Tymnet, the full X.25 calling addresses were obtained 
within seconds of an attack. These addresses pointed to 
sources in Germany: universities in Bremen and Karls¬ 
ruhe, and a public dial-up modem in another German 
city. Vi^hen the intruder attacked the university in Bre¬ 
men, he acquired system-manager privileges, disabled 
accounting, and used their X.25 links to connect 
around the world. Upon recognizing this problem, the 
university traced the connections to the other German 
city. This, in turn, spurred more tracing efforts, coordi¬ 
nating LBL, Tymnet, the university, and the German 
Bundespost. 

Most connections were purposely convoluted. Fig¬ 
ure 1 summarizes the main pathways that were traced, 
but the intruder used other connections as well. The 
rich connectivity and redundant circuits demonstrate 
the intruder’s attempts to cover his tracks, or at least 
his search for new networks to exploit. 

Besides physical network traces, there were several 
other indications of a foreign origin. When the intruder 
transferred files, we timed round-trip packet acknowl¬ 
edgments over the network links. Later, we measured 
the empirical delay times to a variety of different sites 
and estimated average network delay times as a func¬ 
tion of distance. This measurement pointed to an over¬ 
seas origin. In addition, the intruder knew his way 
around UNIX, using AT&T rather than Berkeley UNIX 
commands. When stealing accounts, he sometimes used 
German passwords. In retrospect, all were clues to his 
origin, yet each was baffling given our mind-set that “it 
must be some student from the Berkeley campus.” 

A STINGER TO COMPLETE THE TRACE 

The intruder’s brief connections prevented telephone 
technicians from determining his location more pre¬ 
cisely than to a particular German city. To narrow the 
search to an individual telephone, the technicians 
needed a relatively long connection. We baited the in¬ 
truder by creating several files of fictitious text in an 


obscure LBL computer. These files appeared to be 
memos about how computers were to support research 
for the Strategic Defense Initiative (SDI). All the infor¬ 
mation was invented and steeped in governmental jar¬ 
gon. The files also contained a mailing list and several 
form letters talking about “additional documents avail¬ 
able by mail” from a nonexistent LBL secretary. We 
protected these bogus files so that no one except the 
owner and system manager could read them, and set 
alarms so that we would know who read them. 

While scavenging our files one day, the intruder de¬ 
tected these bogus files and then spent more than an 
hour reading them. During that time the telephone 
technicians completed the trace. We celebrated with 
milk shakes made with homegrown Berkeley straw¬ 
berries, but the celebration proved premature. A few 
months later, a letter arrived from someone in the 
United States, addressed to the nonexistent secretary. 
The writer asked to be added to the fictitious SDI mail¬ 
ing list. As it requested certain “classified information,” 
the letter alone suggested espionage. Moreover, realiz¬ 
ing that the information had traveled from someone in 
Germany to a contact in the United States, we con¬ 
cluded we were witnessing attempted espionage. Other 
than cheap novels, we have no experience in this arena 
and so left this part of the investigation to the FBI. 

BREAK-IN METHODS AND EXPLOITED 
WEAKNESSES 

Printouts of the intruder’s activity showed that he used 
our computers as a way station; although he could be¬ 
come system manager here, he usually used LBL as a 
path to connect to the ARPANET/MILNET. In addition, 
we watched him use several other networks, including 
the Magnetic Fusion Energy network, the High Energy 
Physics network, and several LANs at invaded sites. 

While connected to MILNET, this intruder attempted 
to enter about 450 computers, trying to log in using 
common account names like root, guest, system, oi field. 
He also fried default and common passwords, and often 
found valid account names by querying each system for 
currently logged-in accounts, using who or finger. Al¬ 
though this type of attack is the most primitive, it was 
dismayingly successful: In about 5 percent of the ma¬ 
chines attempted, default account names and pass¬ 
words permitted access, sometimes giving system- 
manager privileges as well. 

When he succeeded in logging into a system, he used 
standard methods to leverage his privileges to become 
system manager. Taking advantage of well-publicized 
problems in several operating systems, he was often 
able to obtain root or system-manager privileges. In any 
case, he searched file structures for keywords like “nu¬ 
clear,” “sdi,” “kh-11,” and “norad.” After exhaustively 
searching for such information, he scanned for plain¬ 
text passwords into other systems. This proved remark¬ 
ably effective: Users often leave passwords in files [2], 
Electronic mail describing log-in sequences with ac¬ 
count names and passwords is commonly saved at for- 
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eign nodes, allowing a file browser to obtain access into 
a distant system. In this manner he was able to obtain 
both passwords and access mechanisms into a Cray su¬ 
percomputer. 

Typical of the security holes he exploited was a bug 
in the Gnu-Emacs program. This popular, versatile text 
editor includes its own mail system, allowing a user to 
forward a file to another user [40], As distributed, the 
program uses the UNIX Set-User-ID-to-Root feature; 
that is, a section of the program runs with system- 
manager privileges. This movemail facility allows the 
user to change file ownership and move files into an¬ 
other’s directory. Unfortunately, the program did not 
prevent someone from moving a file into the systems 
area. Aware of this hole, the intruder created a shell 
script that, when executed at root level, would grant 
him system privileges. He used the movemail facility to 
rename his script to masquerade as a utility periodi¬ 
cally run hy the system. When the script was executed 
by the system, he gained system-manager privileges. 

This intruder was impressively persistent and pa¬ 
tient. For example, on one obscure gateway computer. 


Throughout this time the intruder tried not to de¬ 
stroy or change user data, although he did destroy sev¬ 
eral tasks and unknowingly caused the loss of data to a 
physics experiment. Whenever possible, he disabled ac¬ 
counting and audit trails, so there would be no trace of 
his presence. He planted Trojan horses to passively cap¬ 
ture passwords and occasionally created new accounts 
to guarantee his access into computers. Apparently he 
thought detection less likely if he did not create new 
accounts, for he seemed to prefer stealing existing, un¬ 
used accounts. 

INTRUDER’S INTENTIONS 

Was the intruder actually spying? With thousands of 
military computers attached, MILNET might seem in¬ 
viting to spies. After all, espionage over networks can 
be cost-efficient, offer nearly immediate results, and 
target specific locations. Further, it would seem to be 
insulated from risks of internationally embarrassing 
incidents. Certainly Western countries are at much 
greater risk than nations without well-developed com¬ 
puter infrastructures. 


Was the intruder actually spying? With thousands of military computers attached, MILNET 
might seem inviting . . . espionage over networks can be cost-efficient, offer nearly 
immediate results, and target specific locations. 


he created an account with system privileges that re¬ 
mained untouched until six months later, when he be¬ 
gan using it to enter other networked computers. On 
another occasion, he created several programs that gave 
him system-manager privileges and hid them in system 
software libraries. Returning almost a year later, he 
used the programs to become system manager, even 
though the original operating-system hole had been 
patched in the meantime. 

This intruder cracked encrypted passwords. The 
UNIX operating system stores passwords in publicly 
readable, but encrypted form [26], We observed him 
downloading encrypted password files from compro¬ 
mised systems into his own computer. Within a week 
he reconnected to the same computers, logging into 
new accounts with correct passwords. The passwords 
he guessed were English words, common names, or 
place-names. We realized that he was decrypting pass¬ 
word files on his local computer by successively en¬ 
crypting dictionary words and comparing the results to 
password file entries. By noting the length of time and 
the decrypted passwords, we could estimate the size of 
his dictionary and his computer's speed. 

The intruder understood what he was doing and 
thought that he was not damaging anything. This, alas, 
was not entirely true. Prior to being detected, he en¬ 
tered a computer used in the real-time control of a 
medical experiment. Had we not caught him in time, a 
patient might have been severely injured. 


Some may argue that it is ludicrous to hunt for classi¬ 
fied information over MILNET because there is none. 
Regulations [21] prohibit classified computers from ac¬ 
cess via MILNET, and any data stored in MILNET sys¬ 
tems must be unclassified. On the other hand, since 
these computers are not regularly checked, it is possi¬ 
ble that some classified information resides on them. At 
least some data stored in these computers can be con¬ 
sidered sensitive, ‘ especially when aggregated. Print¬ 
outs of this intruder’s activities seem to confirm this. 
Despite his efforts, he uncovered little information not 
already in the public domain, but that included ab¬ 
stracts of U.S. Army plans for nuclear, biological, and 
chemical warfare for central Europe. These abstracts 
were not classified, nor was their database. 

The intruder was extraordinarily careful to watch for 
anyone watching him. He always checked who was 
logged onto a system, and if a system manager was on, 
he quickly disconnected. He regularly scanned elec¬ 
tronic mail for any hints that he had been discovered, 
looking for mention of his activities or stolen log-in 
names (often, by scanning for those words). He often 
changed his connection pathways and used a variety of 
different network user identifiers. Although arrogant 
from his successes, he was nevertheless careful to cover 
his tracks. 


^ An attempt by the National Security Council [34] to classify certain public 
databases as “sensitive” met with widespread objections [11], 
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Judging by the intruder’s habits and knowledge, he is 
an experienced programmer who understands system 
administration. But he is by no means a “brilliant wiz¬ 
ard,” as might be popularly imagined. We did not see 
him plant viruses [18] or modify kernel code, nor did 
he find all existing security weaknesses in our system. 
He tried, however, to exploit problems in the UNIX/ 
usr/spool/at [36], as well as a hole in the vi editor. 
These problems had been patched at our site long be¬ 
fore, but they still exist in many other installations. 

Did the intruder cause damage? To his credit, he 
tried not to erase files and killed only a few processes. 

If we only count measurable losses and time as damage, 
he was fairly benign [41]. He only wasted systems staff 
time, computing resources, and network connection 
time, and racked up long-distance telephone tolls and 
international network charges. His liability under Cali¬ 
fornia law [6], for the costs of the computing and net¬ 
work time, and of tracking him, is over $100,000. 

But this is a narrow view of the damage. If we in¬ 
clude intangible losses, the harm he caused was serious 
and deliberate. At the least, he was trespassing, invad¬ 
ing others’ property and privacy; at worst, he was con¬ 
ducting espionage. He broke into dozens of computers, 
extracted confidential information, read personal mail, 
and modified system software. He risked injuring a 
medical patient and violated the trust of our network 
community. Money and time can be paid back. Once 
trust is broken, the open, cooperative character of our 
networks may be lost forever. 

AFTERMATH: PICKING UP THE PIECES 

Following successful traces, the FBI assured us the in¬ 
truder would not try to enter our system again. We 
began picking up the pieces and tightening our system. 
The only way to guarantee a clean system was to re¬ 
build all systems from source code, change all pass¬ 
words overnight, and recertify each user. With over a 
thousand users and dozens of computers, this was im¬ 
practical, especially since we strive to supply our users 
with uninterrupted computing services. On the other 
hand, simply patching known holes or instituting a 
quick fix for stolen passwords [27] was not enough. 

We settled on instituting password expiration, delet¬ 
ing all expired accounts, eliminating shared accounts, 
continued monitoring of incoming traffic, setting alarms 
in certain places, and educating our users. Where nec¬ 
essary, system utilities were compared to fresh ver¬ 
sions, and new utilities built. We changed network- 
access passwords and educated users about choosing 
nondictionary passwords. We did not institute random 
password assignment, having seen that users often store 
such passwords in command files or write them on 
their terminals. 

To further test the security of our system, we hired a 
summer student to probe it [2], He discovered several 
elusive, site-specific security holes, as well as demon¬ 
strated more general problems, such as file scavenging. 
We would like to imagine that intruder problems have 
ended for us; sadly, they have not, forcing us to con¬ 
tinue our watch. 


REMAINING OPEN TO AN INTRUDER 

Should we have remained open? A reasonable response 
to the detection of this attack might have been to dis¬ 
able the security hole and change all passwords. This 
would presumably have insulated us from the intruder 
and prevented him from using our computers to attack 
other internet sites. By remaining open, were we not a 
party to his attacks elsewhere, possibly incurring legal 
responsibility for damage? 

Had we closed up shop, we would not have risked 
embarrassment and could have resumed our usual ac¬ 
tivities. Closing up and keeping silent might have re¬ 
duced adverse publicity, but would have done nothing 
to counter the serious problem of suspicious [and possi¬ 
bly malicious) offenders. Although many view the trace 
back and prosecution of intruders as a community serv¬ 
ice to network neighbors, this view is not universal [22], 

Finally, had we closed up, how could we have been 
certain that we had eliminated the intruder? With 
hundreds of networked computers at LBL, it is nearly 
impossible to change all passwords on all computers. 
Perhaps he had planted subtle bugs or logic bombs in 
places we did not know about. Eliminating him from 
LBL would hardly have cut his access to MILNET. And, 
by disabling his access into our system, we v/ould close 
our eyes to his activities; we could neither monitor him 
nor trace his connections in real-time. Tracing, catch¬ 
ing, and prosecuting intruders are, unfortunately, nec¬ 
essary to discourage these vandals. 

LEGAL RESPONSES 

Several laws explicitly prohibit unauthorized entry into 
computers. Few states lack specific codes, but occasion¬ 
ally the crimes are too broadly defined to permit con¬ 
viction [38], Federal and California laws have tight 
criminal statutes covering such entries, even if no dam¬ 
age is done [47], In addition, civil law permits recovery 
not only of damages, but also of the costs to trace the 
culprit [6], In practice, we found police agencies rela¬ 
tively uninterested until monetary loss could be quanti¬ 
fied and damages demonstrated. Although not a substi¬ 
tute for competent legal advice, spending several days 
in law libraries researching both the statutes and prece¬ 
dents set in case law proved helpful. 

Since this case was international in scope, it was nec¬ 
essary to work closely with law-enforcement organiza¬ 
tions in California, the FBI in the United States, and the 
BKA in Germany. Cooperation between system man¬ 
agers, communications technicians, and network opera¬ 
tors was excellent. It proved more difficult to get bu¬ 
reaucratic organizations to communicate with one 
another as effectively. With many organizational 
boundaries crossed, including state, national, commer¬ 
cial, university, and military, there was confusion as to 
responsibility; Most organizations recognized the seri¬ 
ousness of these break-ins, yet no one agency had clear 
responsibility to solve it. A common response was, 
“That’s an interesting problem, but it’s not our baili¬ 
wick,” 

Overcoming this bureaucratic indifference was a con¬ 
tinual problem. Our laboratory notebook proved useful 
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FIGURE 2. Simplified Communications Paths between Organizations 


in motivating organizations: When individuals saw the 
extent of the break-ins, they were able to explain them 
to their colleagues and take action. In addition, new 
criminal laws were enacted that more tightly defined 
what constituted a prosecutable offense [6, 38, 47]. As 
these new laws took effect, the FBI became much more 
interested in this case, finding statutory grounds for 
prosecution. 

The FBI and BKA maintained active investigations. 
Some subjects have been apprehended, but as yet tbe 
author does not know the extent to which they have 
been prosecuted. With recent laws and more skilled 
personnel, we can expect faster and more effective re¬ 
sponses from law-enforcement agencies. 


ERRORS AND PROBLEMS 

In retrospect, we can point to many errors we made 
before and during these intrusions. Like other academic 
organizations, we had given little thought to securing 
our system, believing that standard vendor provisions 
were sufficient because nobody would be interested in 
us. Our scientists’ research is entirely in the public 
domain, and many felt that security measures would 
only hinder their productivity. With increased connec¬ 
tivity, we had not examined our networks for cross¬ 
links where an intruder might hide. These problems 
were exacerbated on our UNIX systems, which are 
used almost exclusively for mail and text processing, 
rather than for heavy computation. 
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The Intruder versus the Tracker 

Skills and techniques to break into systems are quite differ¬ 
ent from those to detect and trace an intruder. The intruder 
may not even realize the route chosen; the tracker, however, 
must understand this route thoroughly. Although both must 
be aware of weaknesses in systems and networks, the for¬ 
mer may work alone, whereas the latter must forge links with 
technical and law-enforcement people. The intruder is likely 
to ignore concepts of privacy and trust during a criminal 
trespass; in contrast, the tracker must know and respect 
delicate legal and ethical restrictions. 

Despite occasional reports to the contrary [19], rumors of 
intruders building careers in computer security are exagger¬ 
ated. Apart from the different skills required, it is a rare 
company that trusts someone with such ethics and personal 
conduct. Banks, for example, do not hire embezzlers as 
consultants. Donn Parker, of SRI International, reports (per¬ 
sonal communication, September 1987) that job applications 
of several intruders have been rejected due to suspicions of 
their character and trustworthiness. On March 16th, the 
Washington Post reported the arrest of a member of the 
German Chaos computer club, prior to his giving a talk on 
computer security in Paris. Others who have broken into 
computers have met with physical violence [33] and have 
been ostracized from network activities [3]. A discipline that 
relies on trust and responsibility has no place for someone 
technically competent yet devoid of ethics. 

Password security under Berkeley UNIX is not opti¬ 
mal; it lacks password aging, expiration, and exclusion 
of passwords found in dictionaries. Moreover, UNIX 
password integrity depends solely on encryption; the 
password file is publicly readable. Other operating sys¬ 
tems protect the password file with encryption, access 
controls, and alarms. 

We had not paid much attention to choosing good 
passwords (fully 20 percent of our users’ passwords fell 
to a dictionary-based password cracker). Indeed, we 
had allowed our Tymnet password to become public, 
foolishly believing that the system log-in password 
should be our only line of defense. 


out of state, we experienced frustration in getting fed¬ 
eral law-enforcement support. Finally, after t.racing the 
intruder abroad, we encountered a whole new set of ill- 
defined interfaces between organizations. The investi¬ 
gation stretched out far beyond our expectations. Na¬ 
ively expecting the problem to be solved by a series of 
phone traces, we were disappointed when the pathway 
proved to be a tangle of digital and analog connections. 
Without funding to carry out an investigation of this 
length, we were constantly tempted to drop it entirely, 

A number of minor problems bubbled up, which we 
were able to handle along the way. For a while this 
intruder’s activity appeared similar to that of someone 
breaking into Stanford University; this confused our in¬ 
vestigation for a short time. Keeping our work out of 
the news was difficult, especially because our staff is 
active in the computing world. Fortunately, it was pos¬ 
sible to recover from the few leaks that occurred. At 
first, we were confused by not realizing the depth or 
extent of the penetrations. Our initial confusion gave 
way to an organized response as we made the proper 
contacts and began tracing the intruder. As pointed out 
by others [25, 36], advance preparations make all the 
difference. 

LESSONS 

As a case study, this investigation demonstrates several 
well-known points that lead to some knotty questions. 
Throughout this we are reminded that security is a 
human problem that cannot be solved by technical so¬ 
lutions alone [48]. 

The almost obsessive persistence of serious penetra- 
tors is astonishing. Once networked, our computers can 
be accessed via a tangle of connections from places we 
had never thought of. An intruder, limited only by pa¬ 
tience, can attack from a variety of directions, search¬ 
ing for the weakest entry point. How can we analyze 
our systems’ vulnerability in this environment? Who is 
responsible for network security? The network builder? 
The managers of the end nodes? The network users? 


Vendors distribute systems with default accounts and backdoor entryways left over from 
software development. Since many customers buy computers based on capability rather than 
security, vendors seldom distribute secure software. 


Once we detected the intruder, the first few days 
were confused, since nobody knew what our response 
ought to be. Our accounting files were misleading since 
the system clocks had been allowed to drift several 
minutes. Although our LAN’s connections had been 
saved, nobody knew the file format, and it was frustrat¬ 
ing to find that its clock had drifted by several hours. In 
short, we were unprepared to trace our LAN and had to 
learn quickly. 

We did not know who to contact in the law-enforce¬ 
ment community. At first, assuming that the intruder 
was local, our district attorney obtained the necessary 
warrants. Later, as we learned that the intruder was 


The security weaknesses of both systems and net¬ 
works, particularly the needless vulnerability due to 
sloppy systems management and administration, result 
in a surprising success rate for unsophisticated attacks. 
How are we to educate our users, system managers, and 
administrators? 

Social, ethical, and legal problems abound. How do 
we measure the harm done by these penetrators? By 
files deleted or by time wasted? By information copied? 
If no files are corrupted, but information is copied, 
what damage has been done? What constitutes unrea¬ 
sonable behavior on a network? Attempting to illicitly 
log in to a foreign computer? Inquiring who is currently 
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logged in there? Exporting a file mistakenly made 
world readable? Exploiting an unpatched hole in anoth¬ 
er’s system? 

Closing out an intruder upon discovery may be a 
premature reflex. Determining the extent of the dam¬ 
age and cooperating with investigations argue for leav¬ 
ing the system open. How do we balance the possible 
benefits of tracking an intruder against the risks of 
damage or embarrassment? 

Our technique of catching an intruder by providing 
bait and then watching what got nibbled is little more 
than catching flies with honey. It can be easily ex¬ 
tended to determine intruders’ interests by presenting 
them with a variety of possible subjects (games, finan¬ 
cial data, academic gossip, military news). Setting up 
alarmed files is straightforward, so this mechanism of¬ 
fers a method to both detect and classify intruders. It 
should not be used indiscriminately, however. 


ing to memorize them are more likely to write such 
passwords into files. How can we make secure remote 
procedure calls and remote batch job submissions? 

Passwords are at the heart of computer security. Re¬ 
quirements for a quality password are few: Passwords 
must be nonguessable, not in a dictionary, changed 
every few months, and easily remembered. User-gener¬ 
ated passwords usually fail to meet the first three crite¬ 
ria, and machine-generated passwords fail the last. Sev¬ 
eral compromises exist: forcing “pass phrases” or any 
password that contains a special character. There are 
many other possibilities, but none are implemented 
widely. The Department of Defense recommends pron¬ 
ounceable machine-generated words or pass phrases 
[5]. Despite such obvious rules, we (and the intruder) 
found that poor-quality passwords pervaded our net¬ 
worked communities. How can we make users choose 
good passwords? Should we? 


Whereas the commercial sector is more concerned with data integrity, the military worries 
about control of disclosure ... we expect greater success for the browser or data thief in the 
commercial world. 


Files with plaintext passwords are common in remote 
job entry computers, yet these systems often are not 
protected since they have little computational capabil¬ 
ity. Such systems are usually widely networked, allow¬ 
ing entry from many sources. These computers are fer¬ 
tile grounds for password theft through file scavenging 
since the passwords are left In easily read command 
procedures, These files also contain instructions to 
make the network connection. Random character pass¬ 
words make this problem worse, since users not wish- 

Legal Constraints and Ethics 

As communities grow, social and legal structures follow. In 
our networked community, there is frustration and confusion 
over what constitutes a crime and what is acceptable behav¬ 
ior. Legal constraints exist, but some do not recognize their 
applicability. Richard D’Ippolito laments: 

Our view of computer crimes has not yet merged with society's 
view of other property crimes: white we have iaws against 
breaking and entering, they aren't wideiy applied to computer 
crimes. The property owner does not have to provide 'perfect' 
security, nor does anything have to be taken to secure a convic¬ 
tion of unauthorized entry. Also, unauthorized use of CPU re¬ 
sources (a demonstrably saieable product) amounts to theft. 

There stiil seems to be the presumption that computer property, 
unlike other property, is fair game .... We deserve the same 
iegal presumption that our imperfectiy protected systems and 
work are private property subject to trespass and conversion 
protection. [12] 

The “ACM Code of Professional Conduct” also leaves little 
doubt: 

An ACM member shall act at all times with integrity ... shall 
always consider the principle of the individual's privacy and to 
minimize the data collected, limit authorized access, [and] pro¬ 
vide proper security for the data.... [1] 


Vendors usually distribute weakly protected systems 
software, relying on the installer to enable protections 
and disable default accounts. Installers often do not 
care, and system managers inherit these weak systems. 
Today, the majority of computer users are naive; they 
install systems the way the manufacturer suggests or 
simply unpackage systems without checking. Vendors 
distribute systems with default accounts and backdoor 
entryways left over from software development. Since 
many customers buy computers based on capability 
rather than security, vendors seldom distribute secure 
software. It is easy to write procedures that warn of 
obvious insecurities, yet vendors are not supplying 
them. Capable, aware system managers with plenty of 
time do not need these tools—the tools are for novices 
who are likely to overlook obvious holes. When ven¬ 
dors do not see security as a selling point, how can we 
encourage them to distribute more secure systems? 

Patches to operating-system security holes are poorly 
publicized and spottily distributed. This seems to be 
due to the paranoia surrounding these discoveries, the 
thousands of systems without systems administrators, 
and the lack of channels to spread the news. Also, 
many security problems are specific to a single version 
of an operating system or require systems experience to 
understand. Together, these promote ignorance of prob¬ 
lems, threats, and solutions. We need a central clear¬ 
inghouse to receive reports of problems, analyze their 
importance, and disseminate trustworthy solutions. 

How can we inform people wearing white hats about 
security problems, while preventing evil people from 
learning or exploiting these holes? Perhaps zero- 
knowledge proofs [20] can play a part in this. 

Operating systems can record unsuccessful log ins. Of 
the hundreds of attempted log ins into computers at- 
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tached. to internet, only five sites (or 1-2 percent) con¬ 
tacted us wlien they detected an attempted break-in. 
Clearly, system managers are not watching for intrud¬ 
ers, who might appear as neighbors, trying to sneak into 
their computers. Our networks are like communities or 
neighborhoods, and so we are surprised when we find 
unneighborly behavior. 

Does security interfere with operational demands? 
Some security measures, like random passwords or 
strict isolation, are indeed onerous and can be self- 
defeating. But many measures neither interfere with 
legitimate users nor reduce the system’s capabilities. 

For example, expiring unused accounts hurts no one 
and is likely to free up disk space. Well thought out 
management techniques and effective security meas¬ 
ures do not bother ordinary users, yet they shut out or 
detect intruders. 

INTERNET SECURITY 

The intruder’s successes and failures provide a reasona¬ 
ble snapshot of overall security in the more than 
20,000 computers connected to Internet. A more de¬ 
tailed analysis of these attacks is to be published in the 
Proceedings of the 2 7 th National Computer Security Confer¬ 
ence [43]. Of the 450 attacked computers, half were 
unavailable when the intruder tried to connect to them. 
He tried to log into the 220 available computers with 
obvious account names and trivial passwords. Of these 
220 attempted log ins, listed in increasing importance, 

• 5 percent were refused by a distant computer (set to 
reject LBL connects), 

• 82 percent failed on incorrect user name/passwords, 

• 8 percent gave information about the system status 
(who, sysstat, etc.), 

• 1 percent achieved limited access to databases or 
electronic-mail shells, 

• 2 percent yielded normal user privileges and a pro¬ 
gramming environment, and 

• 2 percent reached system-manager privileges. 

Most attempts were into MILNET computers (Defense 
Data Network address groups 26.i.j.k). Assuming the 
population is representative of nonmilitary computers 
and the last three categories represent successful pene- 

Should This Have Been Published? 

The very act of publishing this article raises questions. Surely 
it creates a new set of problems by exposing widely distrib¬ 
uted holes to some amoral readers. Worse, it describes 
ways to track such individuals and so suggests avoidance 
techniques, possibly making other intrusions more difficult to 
track and prosecute. 

In favor of publishing, Maj. Gen. John Paul Hyde of the 
U.S. Joint Chiefs of Staff informed the author that "to stimu¬ 
late awareness of the vulnerabilities of networks, along with 
the complexities of tracking a distant intruder, papers such 
as this should be widely distributed. It’s obvious that inatten¬ 
tion to established security practices contributed to the suc¬ 
cess of this intruder; systems with vigilant security programs 
detected and rejected unauthorized accesses.” 


trations, we find that about 5 percent of Internet com¬ 
puters are grossly insecure against trivial attacks. This 
figure is only a lower limit of vulnerability, since mili¬ 
tary computers may be expected to be more secure than 
civilian systems. Further, cleverer tactics for enter¬ 
ing computers could well lead to many more break-ins. 

Whereas the commercial sector is more concerned 
with data integrity, the military worries about control 
of disclosure [8]. With this in mind, we expect greater 
success for the browser or data thief in the commercial 
world. 

In a different set of penetrations [37], NASA experi¬ 
enced about 130 break-ins into its nonclassified, aca¬ 
demic computers on the SPAN networks. Both the 
NASA break-in and our set of intrusions originated in 
West Germany, using similar communications links 
and searching for “secret” information. Pending com¬ 
pletion of law enforcement and prosecution, the author 
does not make conjectures as to the relationships be¬ 
tween these different break-ins. 


Considering the [NASA] break-ins with the 
present study ... break-in success rates of 
3-20 percent may be expected in typical 
network environments. 


Between 700 and 3000 computers are reachable on 
the SPAN network (exact figures depend on whether 
LANs are counted). In that incident the break-in suc¬ 
cess rate was between 4 and 20 percent. Considering 
the SPAN break-ins with the present study, we find 
that, depending on the methods chosen, break-in suc¬ 
cess rates of 3-20 percent may be expected in typical 
network environments. 

CONCLUSIONS AND COMMENTS 

Perhaps no computer or network can be totally secure. 
This study suggests that any operating system will be 
insecure when obvious security rules are ignored. From 
the intruder’s widespread success, it appears that users, 
managers, and vendors routinely fail to use sound secu¬ 
rity practices. These problems are not limited to our 
site or the few dozen systems that we saw penetrated, 
but are networkwide. Lax system management makes 
patching utility software or tightening a few systems 
ineffective. 

We found this intruder to be a competent, patient 
programmer, experienced in several operating systems. 
Alas, .some system managers violate their positions of 
trust and confidence. Our worldwide community of 
digital networks requires a sense of responsibility. Un¬ 
fortunately, this is missing in some technically compe¬ 
tent people. 

Some speak of a “hacker ethic” of not changing data 
[37]. It is astounding that intruders blithely tamper 
with someone else’s operating system, never thinking 
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they may destroy months of work by systems people, or 
may cause unforeseen system instabilities or crashes. 
Sadly, few realize the delicacy of the systems they fool 
with or the amount of systems staff time they waste. 

The foreign origin of the source, the military com¬ 
puters entered, and the keywords searched suggest in¬ 
ternational espionage. This author does not speculate as 
to whether this actually was espionage, but does not 
doubt that someone took the opportunity to try. 


lers, Network Rangers, or various contributors to 2600 
Magazine, it reflects the self-destructive folly of their 
apparent cleverness. 

Tracking down espionage attempts over the digital 
networks may be the most dramatic aspect of this work. 
But it is more useful to realize that analytic research 
methods can be fruitfully applied to problems as bi¬ 
zarre as computer break-ins. 

It seems that everyone wants to hear stories about 


Tracking down espionage attempts over the digital networks may be the most dramatic 
aspect of this work. But it is more useful to realize that analytic research methods can be 
fruitfully applied to problems as bizarre as computer break-ins. 


Break-ins from abroad seem to be increasing. Prob¬ 
ably this individual’s intrusions are different from oth¬ 
ers only in that his efforts were noticed, monitored, and 
documented. LBL has detected other attempted intru¬ 
sions from several European countries, as well as from 
the Orient. Individuals in Germany [37] have claimed 
responsibility for breaking into foreign computers. Such 
braggadocio may impress an unenlightened public; it 
has a different effect on administrators trying to main¬ 
tain and expand networks. Indeed, funding agencies 
have already eliminated some international links due 
to these concerns. Break-ins ultimately destroy the net¬ 
work connectivity they exploit. If this is the object of 
such groups as the German Chaos Club, Data Travel- 


someone else’s troubles, but few are willing to write 
about their own. We hope that in publishing this report 
we will encourage sound administrative practices. Van¬ 
dals and other criminals reading this article will find a 
way to rationalize breaking into computers. This article 
cannot teach these people ethics; we can only hope to 
reach those who are unaware of these miscreants. 

An enterprising programmer can enter many com¬ 
puters, just as a capable burglar can break into many 
homes. It is an understandable response to lock the 
door, sever connections, and put up elaborate barriers. 
Perhaps this is necessary, but it saddens the author, 
who would rather see future networks and computer 
communities built on honesty and trust. 


Computer Security Resources 


Much has been published on how to make a secure operat¬ 
ing system, but there is little literature about frontline encoun¬ 
ters with intruders. Computer security problems are often 
aired over Internet, especially the “UNIX-wizards," “info-vax,” 
and “security" conferences. A lively, moderated discussion 
appears in the Risks Forum [12] addressing social issues 
relating to computer system risks. Private security confer¬ 
ences also exist; their “invitation only” membership is evi¬ 
dence of the paranoia surrounding the field. There are also 
private, anonymous, and pirate bulletin boards. These sel¬ 
dom have much useful information—their puerile contents 
apparently reflect the mind-sets of their contributors, but they 
do indicate what one segment of the population is thinking. 

Perhaps the best review of problems, technology, and pol¬ 
icy is presented in “Defending Secrets, Sharing Data” [32]. 
Whitten provides an excellent introduction to systems prob¬ 
lems in “Computer Insecurity, Infiltrating Open Systems" 

[48]. Although slightly dated, the January 1983 issue of 
Computer [16] is devoted to secure computer systems, with 
a half-dozen good articles on the subject. See the especially 
cogent review article on secure operating systems [15]. Re¬ 
cent work concentrates on secure networks; an entire issue 
of Network is devoted to it [17]. Also see D. Denning’s Cryp¬ 
tography and Data Security [9], and Computer Security: An 
Introduction, by R. Kemmerer at U.C. Santa Barbara. 

Journals of interest include Computer Security Journai, 
Computers and Security, Computer Fraud and Security Buiie- 
tin, ACM SIGPLAN Notices, Computer Security Newsietter, 


Computer Law Journai, and, of course, Communications of 
the ACM. Several semiunderground journals are devoted to 
illicitly entering systems; these are often short lived. The best 
known is 2600 Magazine, named after a frequency used to 
steal long-distance telephone services. 

Current research in computer security covers information 
theory, cryptology, graph theory, topology, and database 
methods. An ongoing debate rages over whether crypto¬ 
graphic protection or access controls are the best choice. 
Since it is tough to prove an operating system is secure, a 
new field of research has sprung up examining ways to for¬ 
mally verify a system’s security. 

The standard for secure operating systems is the Orange 
Book, “DoD Trusted Computer System Evaluation Criteria” 
[29], from the NCSC. This document sets levels of security, 
ranging from class D (minimal protection) through C (discre¬ 
tionary protection), B (mandatory access controls), and A 
(formally verified security controls). Since the Orange Book is 
not easy to comprehend, the NCSC has published an explan¬ 
atory document [30]. There is also a document giving the 
technical rationale behind the explanatory document [28]. 
Some networks link classified computers, and these sys¬ 
tems’ security is being studied and standardized (see [31]). 

UNIX security is covered by Grampp and Morris in [13] 
and by Wood and Kochan in [49]. Wood and Kochan’s book 
is a good guide for system managers and users, although 
much of the book is spent on program listings. More re¬ 
cently, Unix Review presented several articles on securing 
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UNIX [45]. In that issue Smith's article is especially appropri¬ 
ate, as he describes in detail how secure systems are weak¬ 
ened by poor system administration [39], Carole Hogan also 
examines Unix problems in her report. Protection Imperfect, 
available from Lawrence Livermore Labs, L-60; Livermore, CA. 

Operating systems verified to Orange Book security ratings 
include security documentation. For an example of a well- 
written manual, see [10] the DEC VMS System security 
manual. Building a secure operating system is challenging 
and M. Gasser has written a book with just that title, available 
from Van Nostrand and Reinhold. 

Should you have computer security worries, you may wish 
to contact either the National Bureau of Standards (NBS) Insti¬ 
tute for Computer Science and Technology (Mail Stop Tech- 
A216, Washington, DC 20234) or the NCSC (Mail Stop C4. 
9800 Savage Road, Ft. Meade, MD 20755). Both set stan¬ 
dards cind certify secure computers, as well as conduct re¬ 
search in secure networks. Jointly, NBS and NCSC sponsor 
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the annual “National Computer Security Conference." Re¬ 
cently, Federal Law 100-235 has shifted civilian computer se¬ 
curity research from the NCSC to the NBS, apparently wishing 
to separate military and civilian policy. 

With luck, you will never be confronted by a break-in. If you 
are, you can contact your local police, the FBI, or the U.S. 
Secret Service. Within the U.S. Air Force, computer security 
problems are handled by the Air Force Office of Special Inves¬ 
tigations, at Bolling AFB, Washington, D.C. Within other mili¬ 
tary branches, such problems go to the respective investiga¬ 
tive services. MILNET and ARPANET problems should be re¬ 
ported to the Security Office of the Defense Communications 
Agency, which will contact the Network Operations Center at 
BBN Communications. You do not need a court order to trace 
a call on your own line [46]. Most telephone companies have 
security departments that operate trace backs. For a variety of 
ways to respond to a breakin, see “What do you Feed a 
Trojan Horse" [42]. 
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